\subsection{Challenges}
\label{sec:Challenges}

%This Section identifies several challenges that \textsc{Mds} faces, motivated by the previous example. 

\paragraph{Expressiveness}
\label{sec:Expressiveness}

The previous rules already cover a large spectrum: \textsf{R1} is a \emph{permission}; \textsf{R2} and \textsf{R3} are \emph{obligations}; and \textsf{R4} is a \emph{prohibition}. Furthermore, \textsf{R3} and \textsf{R4} depend of \textsf{R2}'s compliance of the doctor, i.e. they become relevant only if \textsf{R2} is violated. A current challenge in \textsc{Mds} is to include in the security model constructs enabling the specification of all these different types of rules. Currently, most of the approaches \cite{Basin2007a,Mouelhi2008,Morin2010a,Basin2011} only deal with access control, which prevent them from capturing many requirements mainly obligation requirements such as those found in \textsc{Hipaa}, \textsc{Glba} and \textsc{Coppa} (Children's Online Privacy Protection Act) \cite{Mont2004a,May2006,Barth2006,Barth2007,Ni2008,Lam2009}.

\paragraph{Abstraction}
\label{sec:Abstraction}

The example rules do not specify how the different artifacts involved are actually represented in their enforcement environment: for example, an action like \textsf{delete} or \textsf{submit} may actually involve several methods whose parameters can depend on each others. Abstraction is actually a very desirable property for enabling simple and intuitive expression and interpretation of security policies. Furthermore, it is often the case that organizations have to comply with mandates generally specified at a high abstraction level, sometimes close to natural language. 

\paragraph{Separation Of Concerns}
\label{sec:SoC}
Information systems are typically designed by different groups of people, each concerned with a particular aspect of the system. Therefore, it is advantageous to enable a clean separation between security policies and system implementation since security officers specifying security policies are typically different from the group of people developing the business logic. This separation of concerns thus simplifies both system development and maintenance. It is also a key enabler for policy reuse within different platforms, or different organizations. 


\paragraph{Traceability}
\label{sec:Mapping}

Although the specification of a security policy should be separated from its enforcement environment, it is necessary to provide a clear and unambiguous interpretation of the policy in its enforcement environment. This means that it is necessary to provide means to precisely map artifacts of security rules to artifacts of the target architecture. In our example for instance, it is necessary to precise what an \emph{administrative} file (\textsf{R}$_4$) is, or what is intended by \emph{encrypted} (\textsf{R}$_5$) in the target system. Note that this link is unfortunately often missing when policies are used to secure information systems. For example, this is generally the case for \textsc{Xacml} policies when developers have to manually devise an \textsc{Xcaml} access request to query the \textsc{Xacml} PDP for decision-making. The absence of a clear documentation allowing a clear traceability link between the security policy and its enforcement environment can make policy enforcement semantics obscure and more vulnerable to security breaches. Providing a full-fledged language that make explicit this correspondence between policy and system entities is therefore needed to help overcoming this point.

\paragraph{Violation Monitoring \& Reaction}
\label{sec:ViolationMonitoringReaction}

How to enforce rules like \textsf{R5}? As a matter of fact, it is not possible to enforce the deletion of a file, and automatic measures may be unsafe. Some security requirements are difficult, or even impossible, to actually enforce within a system. A lightweight solution consists in monitoring the system and to simply detect the fulfillment/violation of a security rule instead of directly enforcing it. Of course, it is necessary in this case to provide means to react to a policy violation. In our example, the rules \textsf{R3} and \textsf{R4} show an example of how new security rules may apply after the violation of other security rules, namely \textsf{R2}.

%It is often important to enforce new rules, or to relax already existing ones. Therefore, an important feature is the ability of having rules depending on other ones. This dependence can be specified \emph{a priori}, like the \textsf{R3} and \textsf{R4} do in our example.  

%This shows the importance of monitoring system compliance with a specified security policy. %, but this also has a cost: efficient monitoring should not hinder system performance drastically, and should not open security holes. 

\paragraph{Policy Runtime Updating}
\label{sec:PolicyRuntimeUpdating}

Organizations are live institutions that evolve: new internal regulations can appear, or old regulations can change, sometimes drastically. For example in our case, if a monthly report is judged too costly, this can be relaxed as a two-months basis. The ability to integrate new security rules and/or to update existing ones is an important aspect to guarantee the continuation of services and to minimize policy update costs. Unfortunately, most \textsc{Mds} approaches focus on design time models, before the security policy is deployed over the system.

\comments{
\paragraph{Security Infrastructure Synchronization} 
\label{sec:InfrastructureGeneration}

To enable full code generation, \textsc{Mds} uses model transformations, generally performed after an analysis phase. One possible \textsc{Mds} approach consists in specifying security concerns within the business model (e.g. using \textsc{Uml} extended with profiles or stereotypes \cite{Jan2002,Lodderstedt2002}). In this case, the generated infrastructure consists of one logical entity after model transformations. One limitation of this approach is that security requirements can only be updated at design time model composition. The other approach consists in keeping security concerns separated from the business logic, by for example using the \textsc{Pep/Pdp} (Policy Enforcement Point / Policy Decision Point) paradigm. A major issue in this context lies in keeping the models synchronized: changes at the security model level are expected to be automatically and correctly deployed and enforced at the system infrastructure level.
}